Skip to content

Add support to search bundles in the host by version range#2036

Closed
laeubi wants to merge 1 commit intoeclipse-pde:masterfrom
laeubi:search_by_version_range
Closed

Add support to search bundles in the host by version range#2036
laeubi wants to merge 1 commit intoeclipse-pde:masterfrom
laeubi:search_by_version_range

Conversation

@laeubi
Copy link
Contributor

@laeubi laeubi commented Oct 22, 2025

Currently PDE#findPluginInHost assumes that a bundle is unique by its id what is not true in all cases.

This now do the following:

  • index the plugins by id but keep them in a list to support multiple
  • if more than one version is found return the highest
  • allow to further restrict by version range

This is in preparation of the new JUnit 6 support where the host will contain two bundles with same name but different version, but this can happen today as well e.g. different guava and whatever.

Currently PDE#findPluginInHost assumes that a bundle is unique by its id
what is not true in all cases.

This now do the following:

- index the plugins by id but keep them in a list to support multiple
- if more than one version is found return the highest
- allow to query all models for an id
@laeubi laeubi force-pushed the search_by_version_range branch from 9560528 to 276b97e Compare October 22, 2025 07:54
@github-actions
Copy link

Test Results

   771 files  ±0     771 suites  ±0   1h 7m 43s ⏱️ - 2m 33s
 3 609 tests ±0   3 556 ✅  - 1   52 💤 ±0  1 ❌ +1 
10 827 runs  ±0  10 669 ✅  - 1  157 💤 ±0  1 ❌ +1 

For more details on these failures, see this check.

Results for commit 276b97e. ± Comparison against base commit 9851080.

@HannesWell
Copy link
Member

This is in preparation of the new JUnit 6 support where the host will contain two bundles with same name but different version, but this can happen today as well e.g. different guava and whatever.

I have to admit that I fail to see what the advantage is of effectivly extracting this change from #2013, which is hopefully ready very soon?
Technicaly this is valid, but as this change is also included in #2013, but in a slightly different variant, we should not further complicate that PR and not have this change in a separate PR.

@laeubi
Copy link
Contributor Author

laeubi commented Oct 23, 2025

Closing in favor of

I thing we should use some improvements here but this can be done later on.

@laeubi laeubi closed this Oct 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants